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This is an appeal pursuant to 35 U.S.C. § 134 from the Examiner's decision rejecting 
claims 1-2 and 4-21 as set forth in the Office Action of February 9, 2007. 
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I. Real Party in Interest 

The real party in interest in this application and the appeal is XM Satellite Radio Inc. by 
assignment recorded February 28, 2001 on Reel 01 1544, Frame 0098. 



II. Related Appeals and Interferences 

There are no other related patents or applications related to this invention on appeal or 
that are involved in an interference proceeding. 



III. Status of Claims 

Claims 1-2 and 4-21 stand finally rejected and are the subject of this appeal. Claims 1-2 
and 4-21 are reproduced in the Claims Appendix (Section VIII). 



IV. Status of Amendments 

No amendments were filed subsequent to the February 9, 2007 final rejection. 
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V. 



Summary of the Claimed Subject Matter 



Briefly, the present invention is directed to a receiver, as recited in independent claim 1, 
for receiving, processing and storing segments in a data file that were interspersed in a broadcast 
signal. The receiver monitors the progress of receiving the segments that constitute the data file. 
The present invention is also directed to methods of transmitting and receiving segments from 
partitioned data files that are interspersed in a broadcast signal, as recited in independent claims 
1 3 and 17, respectively. The present invention partitions and transmits data files as claimed to 
minimize impact on system bandwidth requirements for transmitting other broadcast content (see 
page 2, line 20 to page 3, line 2) and does not require a back channel between a receiver and a 
broadcast station to overcome data loss due to obstructions, interference or other interruptions 
during file transfer (see page 3, lines 18-21). 

Independent claim 1 is directed to a receiver 14 in a digital broadcast system 10 (page 5, 
lines 21-30; Fig. 1). The receiver 14 (Fig. 7) has a memory device 50 (page 9, lines 6-14), a 
reception device 52, 55, 58 and a processing device 60 (page 9, line 15 to page 10, line 16). The 
memory device 50 stores content from a transmitted broadcast signal 30 (Fig. 2, page 6, lines 7- 
16 and page 7, lines 25-27) using the digital broadcast system 10. The content comprises data 
files 34 (Fig. 3, page 7, lines 5-6 and 18-20). The data files 34 are each partitioned into 
segments 36 (Fig. 4, page 7, lines 19-23) that are interspersed in the transmitted broadcast signal 
30. The transmitted broadcast signal is provided with at least one header 37 (Fig. 5, page 7, 
lines 24-25 and page 7, line 29 to page 8, line 8) comprising information 42 indicating the 
number of said segments that constitute at least one of said data files and information 41 to 
identify each of said segments (Fig. 5, page 8, lines 4-7). The reception device receives the 
broadcast signal 30 and processes the broadcast signal to obtain at least part of the content 
including those segments 36 corresponding to at least one of the data files 34 therein (page 9, 
line 29 to page 10, line5). The processing device 60 connected to the memory device 50 and the 
reception device 52, 55 and 58 is programmable to use the header in the broadcast signal to 
determine the size of at least one section in the memory device 50 to allocate for storing the data 
file 34, to store the segments 36 corresponding to the data file 34 in the allocated section (page 
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10, lines 17-26), and to monitor the progress of the storage of the segments in said allocated 
section (page 11, lines 9-26). The header has data to indicate how much of the memory device 
needs to be allocated to store the file (page 7, line 26 through page 8, line 6, and page 10, lines 

17- 21). 

Independent claim 13 is directed to a method of transmitting content comprising data 
files 34 (Fig. 3, page 7, lines 18-21). The method comprises assigning each of said data files 34 
a message identification code 38 (Fig. 5, page 7, line 28-30, page 8, lines 12-14, page 10, lines 
8-14) to indicate which of a plurality of receivers in said digital broadcast system are to receive 
the corresponding data file. The method also comprises partitioning the data files 34, each 
being partitioned into segments 36 (Fig. 4, page 7, lines 19-23). The method involves assigning 
the segments 36 in respective data files 34 with unique identification codes that indicate the 
order of the segments in a corresponding one of the data files 34 (page 7, line 29 to page 8, line 
1 and page 8, lines 3-7). The segments are interspersed in the broadcast signal 30 (page 7, lines 
21-23). The broadcast signal 30 is provided with segment headers 37 for respective ones of the 
segments 36 that each comprise a corresponding the message identification code 38, a first field 
42 indicating the total number of the segments in the corresponding one of the data files 34, and 
a second field 41 indicating the identification code of the segment (Fig. 5, page 7, line 28 to 
page 8, line7). 

Independent claim 17 is directed to a method of implementing a file transfer from a 
broadcast station 18, 20 to a receiver 14 in a digital broadcast system 10 (Fig. 1, page 7, lines 

18- 21, page 8, lines 15-16). The method involves receiving a transmitted broadcast signal 30 
having content, the broadcast signal having content comprising data files 34 (Figs. 2 and 3, page 
9, lines 7-9). The data files 34 are each being partitioned into segments 36 (Fig. 4, page 7, lines 
18-23) that are interspersed in the broadcast signal 30. The broadcast signal 30 is provided with 
at least one header 37 comprising information 42 and 41, respectively, indicating the number of 
segments that constitute at least one of the data files 34 and identifying each of the segments 
(Fig. 5, page 8, lines 4-7). The method involves selecting one of the data files 34 to store in a 
memory device 50 (page 9, lines 23-28), and allocating a portion of the memory device 50 that 
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corresponds in size to the number of the segments 36 that constitute the selected data file 34 as 
indicated by the information in the at least one header 37 (page 10, lines 17-21). The 
information 41, 42 in the at least one header 37 is analyzed to identify the segments 36 received 
via the broadcast signal 30 and corresponding to the selected data file (page 8, lines 4-7, page 9, 
line 29 to page 10, line 5, page 11, lines 23-26). The segments are then stored in the portion of 
the memory device that corresponds to the selected data file (page 10, lines 4-5). 



VI. 



Grounds of Rejection to be Reviewed on Appeal 



The grounds of rejection for review on appeal are: 

(1) whether independent claims 1 and 17 and dependent claims 4-5, 9 and 18 are 
unpatentable under 35 U.S.C. § 103(a) as obvious over U.S. Patent No. 6,801,536, 
to Foster et al., in view of U.S. Patent No. 5,801,781, to Hiroshima et al; 

(2) whether dependent claims 2, 10 and 19 are unpatentable under 35 U.S.C. § 103(a) 
as obvious over U.S. Patent No. 6,801,536, to Foster et al., in view of U.S. Patent 
No. 5,801,781, to Hiroshima et al, and further in view of U.S. Patent No. 
5,732,324, to Rieger, III; 

(3) whether dependent claims 6-7 and 20-21 are unpatentable under 35 U.S.C. § 
103(a) as obvious over U.S. Patent No. 6,801,536, to Foster et al., in view of U.S. 
Patent No. 5,801,781, to Hiroshima et al, and further in view of U.S. Patent No. 
5,815,671, to Morrison; 

(4) whether dependent claim 8 is unpatentable under 35 U.S.C. § 103(a) as obvious 
over U.S. Patent No. 6,801,536, to Foster et al., in view of U.S. Patent No. 
5,801,781, to Hiroshima et al, and further in view of U.S. Patent No. 5,815,671, to 
Morrison, and U.S. Patent Application Publication No. 2003/0212996, to 
Wolzien; 

(5) whether dependent claim 1 1 is unpatentable under 35 U.S.C. § 103(a) as obvious 
over U.S. Patent No. 6,801,536, to Foster et al., in view of U.S. Patent No. 
5,801,781, to Hiroshima et al, and further in view of U.S. Patent No. 5,732,324, to 
Rieger, III, and U.S. Patent No. 5,815,671, to Morrison; 

(6) whether independent claim 13 and dependent claims 14 and 15 are unpatentable 
under 35 U.S.C. § 103(a) as obvious over U.S. Patent No. 6,801,536, to Foster et 
al., in view of U.S. Patent No. 5,815,671, to Morrison; and 

(7) whether dependent claim 16 is unpatentable under 35 U.S.C. § 103(a) as obvious 
over U.S. Patent No. 6,801,536, to Foster et al., in view of U.S. Patent No. 
5,815,671, to Morrison, and further in view of U.S. Patent Application 
Publication No. 2003/0212996, to Wolzien. 
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VII. Arguments 



A. Claims 1-2 and 4-21 Are Not Obvious Over U.S. Patent No. 6,801,536 to 

Foster et al. in view of Cited Secondary References 

1. Independent Claims 1 and 17 Are Not Obvious over Foster et al 
in view of Hiroshima et al 

Claims 1, 4-5, 9, 12, 17 and 18 are rejected under 35 U.S. C § 103(a) as being unpatentable 
over U.S. Patent No. 6,801 ,536, to Foster et al (hereinafter "Foster et al") in view of U.S. Patent 
No. 5,801,781, to Hiroshima et al (hereinafter "Hiroshima et al") . 

Applicant respectfully submits that neither Foster et al nor Hiroshima et al, singly or in 
combination, teaches or suggests at least the following recitations of independent claim 1: 

". . .storing content from a transmitted broadcast signal using said digital 
broadcast system, the content comprising data files, 

said data files each being partitioned into segments that are interspersed in said 
transmitted broadcast signal, 

said transmitted broadcast signal being provided with at least one header 
comprising information indicating the number of said segments that constitute at least 
one of said data files and information to identify each of said segments;. . . 

. . .use said at least one header in said transmitted broadcast signal to determine 
the size of at least one section in said memory device to allocate for storing the data 
file, said at least one header comprising data to indicate how much of said memory 
device needs to be allocated to store the data file, " 

monitor the progress of the storage of said segments in said allocated section, 
among other recited elements. 

Applicant maintains that the Examiner improperly relies on operations of the set top box 
(STB) on received PES streams described in Foster et al (e.g., creation of sub blocks as 
described in the referenced text in columns 6-8 of Foster et al) with respect to the transport 
stream 210 described in columns 4 and 5 of Foster et al. Applicant has set forth the reasons for 
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this improper use of Foster et al in the Amendment dated November 16, 2006 and in the Appeal 
Brief dated February 28, 2006. The reasons are repeated below under the sub-heading "a. 

Misapplication of Foster et al to Reject Claims ." 

Further, the Advisory Action states that Applicant's remarks are not convincing because 
Applicant argues against the Hiroshima et al reference individually. The Advisory Action cites 
case law in support of a statement that one cannot show non-obviousness by attacking references 
individually where the rejections are based on combinations of references. In the instant 
application, however, Applicant properly attacks an applied reference individually when it is 
necessary to explain why the reference does not teach a part of a combination proposed by the 
Examiner that the Examiner claims the reference to teach. After attacking an individual 
reference in this manner, Applicant also properly indicates when a second reference does not 
make up for the deficiency of the first reference as argued by the Applicant. 

a. Misapplication of Foster et al to Reject Claims 

This text is repeated in part from the Amendment dated November 16, 2006 and in part 
from the Appeal Brief dated February 28, 2006. 

Foster et al has been applied to reject claims for purportedly teaching several aspects of 
claim 1. Applicant respectfully submits that the Examiner has misinterpreted and misapplied the 
Foster et al to reject the claims. Foster et al discloses a system for buffering MPEG transport 
streams in a set- top box. The set-top box depicted in Fig. 2 of Foster et al divides an MPEG 
transport stream 210 into sub-blocks. The Examiner has improperly and arbitrarily switched 
between referring to (1) the packets in the transport stream and (2) the subblocks built at the set- 
top box to state which aspects of the system disclosed in Foster et al purportedly teach the recited 
elements in the claims. If the packets in the transport stream of Foster et al could arguably be 
considered data files as claimed, then the recitations in claim 1 regarding storing and monitoring 
progress of segments of a data file cannot be met by the processing of the transport data stream 
packets at the STB. Further, the subblocks cannot be argued to teach segments as claimed since 
they are created at the STB and therefore after transport. 

The Examiner has been requested to reconcile an apparently contrary position with regard 
to Fig. 2 depicting an STB having the queues and multiplexer and block 310 of Fig. 3, which 
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clearly indicates reception of the transport stream at the STB prior to building sub-blocks (which 
represent a selected number of bytes of a PES packet for improved STB buffering), or building 
the sub-block headers which the Examiner has incorrectly relied on to teach the claimed concepts 
of allocating memory and monitoring progress of segment storage as claimed. The Examiner has 
also been asked to reconcile his position with the text at column 8, lines 14-34 of Foster et al. 

The subblocks in Foster et al cannot be argued to teach segments as claimed since they 
are created at the STB and therefore after transport. Blocks 310 and 340 in Fig. 3 of Foster et al 
clearly indicate that the system in Foster et al receives a transport stream and then builds sub- 
blocks. Foster et al does not create sub-blocks prior to transport and therefore does not teach or 
suggest storing content in a broadcast signal having data files partitioned into segments 
interspersed a broadcast signal, as claimed. 

There are numerous passages throughout the text of Foster et al that describe defining and 
building subblocks and data blocks at the set-top box (STB) and therefore after transport and 
after reception of a transport stream. The STB receives a transport stream 210 (e.g., packets of 
188 bytes including a four byte header) at demultiplexer 110, and converts it to a packetized 
elementary stream format (PES) including separate audio and video streams that are provided to 
separate queues (see column 3, line 61 to column 4, line 2 and column 4, lines 38-41). A byte-to- 
interrupt (BTI) signal determines when subblocks are formed in the STB and sent to a queue in 
the STB (see column 6, lines 1-49). This is most plainly evident from Fig. 3 of Foster et al, 
where it is clearly shown that the transport stream is received (block 3 1 0), and then the 
subblocks are defined via queues for audio and video (block 320), and then the sub block 
headers are built (block 340), as described at column 5, line 43 through column 6, line 49 of 
Foster et al. See also Fig. 1 where a transport stream is input to a transport demux 1 10 of a STB 
chip 100. See also Fig. 2 where the transport demux 220 of the STB chip has audio and data 
buffers 222A and 222V. As stated at column 6, lines 23-25 of Foster et al, a bytes-to-interrupt 
(BTI) signal is a "rolling interrupt that indicates when a given number of bytes (in 256 byte 
increments),ybrwmg sub-blocks (emphasis added) have been sent to a queue." Thus, the 
subblocks are created at the STB chip 100 and therefore after transport. See also column 5, lines 
56 and 57 which states that the transport packets are received in the correct order which enables 
the buffers 222A and 222V to be in the transport demultiplexer of the STB (i.e., transport 
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demultiplexer 220 in Fig. 2 or transport demultiplexer 1 10 in Fig. 1). See column 6, lines 38-42 
of Foster et al which state "Upon the issuance (330 of Fig, 3) of each BTI interrupt and as a data 
block is sent to multiplex buffer 280, a header is created (emphasis added) for each sub 
block...." The "information for the header is developed concurrently (emphasis added) with the 
storage of data subblocks to the multiplex buffer 280. As stated at column 6, lines 45-49 of 
Foster et al, sub block and their headers are read out from buffers by queuing for storage. Thus, 
all of these receiving, buffering/queuing, sub block and header building operations are performed 
at the STB after the transport stream 110 (Fig. 1) or 210 (Fig. 2) is received. See also the claims 
of Foster et al. Claim 2 of Foster et al recites steps for defining subblocks using BTI values and 
queuing controlled by same. Claim 5 recites building a header after buffering and defining 
subblocks. To interpret the transport stream to the STB in Foster et al as already having 
subblocks prior to transport is contrary to the disclosure in Foster et al. 

Further, neither the packets in the transport stream 210 nor the subblocks in Foster et al 
indicate the number of segments that constitute a partitioned file nor identify each segment, as 
claimed in claim 1 . The bytes-to-interrupt (BTI) values of Foster et al relied on in the final 
Office Action are added at the set-top box and therefore after transport. Further, the BTI values 
are merely time reference stamps that do not indicate the number of segments that constitute a 
data file in a broadcast signal, as claimed. 

If the packets in the transport stream of Foster et al could arguably be considered data 
files as claimed, then the recitations in claim 1 regarding storing and monitoring progress of 
segments of a data file cannot be met by the processing of the transport data stream packets at the 
STB. The Office Action apparently analogizes packets in a transport stream 210 of Foster et al 
to be data files as claimed, and bytes in those packets to be segments as claimed. This is incorrect 
since the bytes of a packet are not interspersed in the transport stream of Foster et al, in contrast 
to segments of the data file recited in claim 1 being interspersed in a broadcast signal. Secondly, 
the buffers 222 A and 222V in Foster et al do not monitor progress of storage of bytes in a 
particular packet, nor even the progress of storing packets. Mere sizing of a buffer to control 
when it is filled and when it is read from does not constitute monitoring progress of reception of 
bytes associated with a packet. Also, it is impermissible to change the apparent analogy in the 



- 10- 



office action to purport that a packet in Foster et al teaches a segment as claimed, rather than a 
transport packet byte, since there is no discussion in Foster et al of relating the packets to a 
particular data file that has been partitioned into packets. For example, unlike the claimed 
invention, there is no disclosure or suggestion in Foster et al of a file being segmented into a 
plurality of packets, and a header being provided in the transport stream to indicate the number 
of packets that constitute that file. The headers of the transport stream packets of Foster et al 
merely identify the type of data (e.g., audio or video) in the packet, but do not relate the packets 
to others that constitute a data file, unlike the claimed segments and header 

The Office Action also references column 4, lines 55-67 and column 5, lines 43-67 of 
Foster et al to purportedly teach a transmission signal made up of packets having a header as 
claimed. First, as stated above, the packets and packet bytes of the transport stream of Foster et 
al bear no analogy to the recited data files and segments. Second, the text at column 4, lines 55- 
67 of Foster et al has been mischaracterized in the office action. The text merely states how a 
transport packet header can indicate the number and correspondence of transport stream bytes in 
transport stream packets to packets in PES steams created at the STB (e.g., the PES packets are 
large compared to the size of the transport packets). The PESs, however, are created at the STB 
as stated above and therefore cannot teach or suggest a data file as claimed. 

The Office Action refers to column 5, lines 43-55 to purportedly teach the data files, 
segments and headers as recited in claim 1 . This text, however, refers to interspersing transport 
stream packets into PES streams that are created at the STB, and therefore does not teach or 
suggest segments interspersed in a broadcast stream prior to transport. 

In view of the above, Foster et al fails to teach or suggest the invention recited in claim 1. 

b. Hiroshima et al does not cure the deficiencies of Foster et al 

The Examiner admits in the final Office Action that Foster et al "does not clearly disclose 
the use of the header comprising data to indicate how much of the memory device need [sic] to 
be allocated to store the data file." 
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Hiroshima et al is relied on to purportedly overcome this deficiency by referring to Fig. 6 
therein and specifically to element 122 and column 8, lines 32-45. Element 122 indicates buffer 
size in a system header 90 as described in column 8, lines 32-45 of Hiroshima et al, but appears 
to be part of a packet 92 as illustrated in Fig. 6. Although unclear, Applicant assumes the 
described system header 90 is interpreted as a packet header by the Examiner, and that the buffer 
size 122 is part of the system header 90, since the final Office Action states that "it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to modify 
Foster with Hiroshima for having a buffer size with a packet header so to guarantee neither 
overflow nor underflow of the buffers." 

First, the element 122 for buffer size in Fig. 6 of Hiroshima et al does not teach (1) "said 
transmitted broadcast signal being provided with at least one header comprising information 
indicating the number of said segments that constitute at least one of said data files and 
information to identify each of said segments ," or (2) receiving the transmitted broadcast signa l 
and processing it to obtain at least part of content including the segments, or (3) a processing 
device connected to the reception device and a memory device for using the header to determine 
the size section of the memory device to allocate for storin g the data file , as recited in claim 1. 
Fig. 6 refers to a conversion process for changing an MPEG1 system stream to resultant data as 
an MPEG2-TS (see Hiroshima et al, column 7, line 58 to column 8, line 7). Thus, the system 
header 90 with buffer size 122 used in the conversion process do not relate in any way to a 
transmitted broadcast signal having data files partitioned into segments and a header as claimed 
that can be used to allocate memory once the transmitted broadcast signal is received. 

Second, if the buffer size 1 22 in Hiroshima et al is interpreted to be in a header of a 
packet and the system header 90 is relied on to teach a header as recited in claim 1 , then 
Applicant respectfully submits that the system header 90 fails to teach or suggest "at least one 
header comprising information indicating the number of said segments that constitute at least 
one of said data files and information to identify each of said segments " as recited in claim 1 . 
The final Office Action does not set forth what is regarded in Hiroshima et al as purportedly 
teaching a segment in a data file as recited in claim 1 . For example, assuming that a packet 92 in 
Hiroshima et al is regarded as arguably teaching a segment in a pack 86 that is, in turn, assumed 
arguably to be a data file, then the system header 90 does not contain information to identify 
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each of the packets 92,. . .,94 nor the number of packets in the data file. By contrast, claim 1 
recites a header comprising information indicating the number of said segments that constitute at 
least one of said data files and information to identify each of said segments , among other 
elements. 

Third, as recited in claim 1, the header in the transmitted broadcast signal is used to 
determine the size of at least one section in a memory device to allocate for storing the data file. 
Hiroshima et al is silent regarding what the buffer size 122 corresponds to. In the response to 
final Office Action submitted on May 9, 2007, Applicant requested another non-final office 
action that clearly articulated the Examiner's rejections in accordance with 37 C.F.R. 1.104, or 
allowance of the above-identified application, neither of which were granted. 

Finally, the Advisory Action also stated that certain remarks of Applicant regarding the 
differences between the claimed invention and MPEG as used by the Examiner to reject claims 
could not be imported into the claim in question, and therefore were not considered. Applicant 
respectfully submit, however, that claim language was identified in the response to final Office 
Action submitted on May 9, 2007 to show a patentable difference between the recited invention 
and the Examiner's use of MPEG. MPEG, which is mentioned in Hiroshima et al and in Foster 
et al and apparently relied on by the Examiner, does not provide information to determine the 
size of memory to allocate to store a data file as claimed as the Examiner suggests since stream 
ids, presentation time stamps, and the like are for temporary memory consumed by an MPEG 
decoder for a decoding a packet but not for a data file in a stream. The temporary buffering of 
packets by MPEG allows for real-time playback. The Examiner acknowledges on page 4 of the 
Office Action that Foster with Hiroshima as proposed by the Examiner is to guarantee that 
neither overflow nor underflow of the buffers occurs. Foster et al describes the "leaky bucket 
model" of MPEG2 in column 5, lines 61-67 which supports characterization of MPEG as being 
concerned with temporary buffering for decoding purposes for real-time playback. By contrast, 
the invention recited in claim 1 uses the header received with the transmitted broadcast signal to 
determine "the size of at least one section in said memory device to allocate for storing the data 
file." The header comprises the "information indicating the number of segments that constitute 
at least one of the data files and information to identify each of said segments," as recited in 
claim 1. As explained in the present application on page 7, lines 13-25, such partitioning of data 
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files into segments and use of headers to facilitate capture and storage of the received data file 
obviates the need for a significant amount of the instantaneous broadcast system bandwidth to 
broadcast the data file as one unit. 

To reject claims 4, 5, 9, 12, 17 and 18, the Office Action continues to rely on sections of 
Foster et al relating to operations of the STB. As discussed above, reliance on the teachings of 
Foster et al at the STB to reject claims 4, 5, 9, 12, 17 and 1 8 is improper since Foster et aPs 
subblocks are not part of the transmitted signal. 

Independent claim 17 recites substantially the same aspects of the present invention as 
claim 1 . In view of the foregoing, withdrawal of the rejection of claims 1, 4-5, 9, 12, 17 and 18 
under 35 U.S.C § 103(a) is respectfully requested. 

2. Claims 2, 10 and 19 Are Not Obvious over Foster et al in view of 
Hiroshima et al and Rieger III 

In the Office Action, claims 2, 10 and 19 are rejected under 35 U.S.C § 103(a) as being 
obvious over Foster et al in view of Hiroshima et al and further in view of U.S. Patent No. 
5,732,324, to Rieger III (hereinafter "Rieger III"). Claim 2 recites generating an alert message 
when segments in a data file are received. As recited in claim 1 from which claim 2 depends, a 
data file is characterized in a broadcast signal by a header indicating the number of segments 
that constitute the data file. Rieger III is relied on for its purported disclosure of alerting a user 
when data segments have been stored in a memory device as claimed in claim 2. 

Regarding claim 2, Applicants respectfully submit that Rieger III does not disclose 
alerting as claimed, and that the Rieger III does not overcome the deficiencies of Foster et al in 
view of Hiroshima et al stated above. Rieger III teaches sending audio programs from low 
power transmitters to proximate digital burst radio (PDBR) receiving units in motor vehicles. 
The programs have preambles identifying programs by a brief textual description and date or 
creation. Thus, Rieger III does not teach a header comprising information indicating the 
number of said segments that constitute a data file. Rieger III merely teaches that a receiving 
unit can use the preamble to filter previously received programs based on the brief textual 
description and date of creation in the preamble. Rieger III, however, cannot use the preamble 
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to "monitor the progress of storage of said segments" as recited in claim 1. Rieger III merely 
teaches determining if an entire program is received and stored, and not its progress or parts of 
the program. 

Claim 10 recites determining which segments of a rebroadcast data file have been 
stored, storing those rebroadcast segments of the data file that are not yet in a memory device 
and ignoring those rebroadcast segments of the data file that are already stored. Rieger, III 
discloses filtering programs that are already captured at a receiver, but not determining whether 
parts of programs have been received or not. 

Regarding claim 1 9, Foster et al and Hiroshima et al are deficient for the reasons stated 
above with respect to claims 17 and 18. Rieger III discloses filtering programs that are already 
captured at a receiver, but not determining whether parts of programs have been received or not. 
Further, Rieger III does not overcome the deficiencies of Foster et al and Hiroshima et al 
discussed above. 

In view of the foregoing, Applicant respectfully requests withdrawal of the 35 U.S.C 
§ 103(a) rejection of claims 2, 10 and 19. 

3. Claims 6-7 and 20-21 Are Not Obvious over Foster et al in view of 
Hiroshima et al and Morrison 

In the Office Action, claims 6, 7 and 20-21 are rejected under 35 U.S.C § 103(a) as 
being obvious over Foster et al in view of Hiroshima et al and further in view of U.S. Patent No. 
5,8 1 5,67 1 , to Morrison (hereinafter "Morrison"). 

Regarding claim 6, the Office Action acknowledges that Foster et al in view of 
Hiroshima et al fails to show a data field comprising an expiration data for the data file. 

Further, regarding claims 6 and 7, Morrison is relied on for its purported disclosure of 
message data codes in sent data. Applicant respectfully submits that Morrison does not 
overcome the deficiencies of Foster et al in view of Hiroshima et al. Morrison does not teach or 
suggest a data file characterized in a transmitted broadcast signal by a header indicating the 
number of segments that constitute the data file, among other aspects of the claimed invention. 

Claim 20 depends from base claim 1 7 which recites, among other elements, a portion of 
memory is allocated to correspond in size to the number of segments in a data file. Claim 20 
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recites determining that this allocated portion of memory is a selected percentage full before 
tuning to a scheduled rebroadcast to extract segments not yet received. Accordingly, the 
inherency argument presented in the Office Action that a storage device is "always a 
'percentage full 5 " does not teach or suggest the allocated memory portion that is monitored for 
fullness before automatic tuning as claimed. Further, regarding claims 20 and 21, Morrison 
does not overcome the deficiencies of Foster et al and Hiroshima et al discussed above in 
connection with claims 1 and 17. Accordingly, Applicant requests withdrawal of this basis for 
rejecting claims 6, 7, 20 and 21 under 35 U.S.C § 103(a). 

4. Claim 8 Is Not Obvious over Foster et al in view of Hiroshima et al, 
Morrison and Wolzien 

Claim 8 is rejected under 35 U.S.C § 103(a) as being obvious over Foster et al in view of 
Hiroshima et al and further in view of Morrison and further in view of U.S. Patent Application 
Publication No. US 2003/0212996, to Wolzien (hereinafter "Wolzien"). Paragraph [0058] of 
Wolzien is relied on for its purported disclosure of code identification information that identifies 
a type of car for a user profile to facilitate an automated push information operation. Applicant 
respectfully submits that Wolzien does not overcome the deficiencies of Foster et al and 
Hiroshima et al. Further, none of these references singly or in combination teaches or suggests 
the invention recited in claim 1, the base claim from which claim 8 depends for reasons set forth 
above. For example, Wolzien does not teach or suggest partitioning of a data file in a broadcast 
signal into segments and providing headers in the transmitted broadcast signal to indicate the 
number of segments in a data file, as recited in claim 1. Applicant therefore respectfully 
requests withdrawal of this basis for rejecting claim 8 under 35 U.S.C § 103(a). 

5. Claim 11 Is Not Obvious over Foster et al in view of Hiroshima et al, 
Rieger III and Morrison 

Claim 1 1 is rejected under 35 U.S.C § 103(a) as being obvious over Foster et al in view 
of Hiroshima et al and further in view of Rieger III and further in view of Morrison. None of 
these references, however, singly or in combination teaches or suggests the invention recited in 
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claims 1 or 10, the base and intervening claims from which claim 11 depends for reasons set 
forth above. Applicant therefore respectfully requests withdrawal of this basis for rejecting 
claim 1 1 under 35 U.S.C § 103(a). 

6. Claims 13-15 Are Not Obvious over Foster et al in view Morrison 

Claims 13-15 rejected under 35 U.S.C § 103(a) as being obvious over Foster et al in 
view of Morrison. 

The STC of Foster et al is relied on to purportedly teach providing each segment with a 
header that identifies the total number of segments and an identification code. Independent 
claim 13, however, provides the segments to the broadcast signal. Foster et al cannot suggest 
segment codes as claimed since the STC relied on in Foster et al is a local System Time Clock 
(i.e., local to the STB) that is updated at the STB using the transmitted PCR data and then 
coded into a header (see column 7, lines 65 through column 8, lines 1-5 and 23-28). Morrison 
does not overcome the deficiencies of Foster et al. Accordingly, Applicant respectfully requests 
withdrawal of this basis for rejecting claim 13 and its dependent claims 14-15 under 35 U.S.C 
§ 103(a). 

7. Claim 16 Is Not Obvious over Foster et al in view Morrison and 
Wolzien 

Claim 16 is rejected under 35 U.S.C § 103(a) as being obvious over Foster et al in view 
of Morrison and further in view of Wolzien. Paragraph [0058] of Wolzien is relied on for its 
purported disclosure of code identification information that identifies a type of car for a user 
profile to facilitate an automated push information operation. Applicant respectfully submits 
that Wolzien does not overcome the deficiencies of Foster et al and Morrison. Further, none of 
these three references singly or in combination teaches or suggests the invention recited in claim 
13, the base claim from which 16 depends for reasons set forth above. For example, Wolzien 
does not teach or suggest partitioning of a data file in a broadcast signal into segments and 
providing headers in the transmitted broadcast signal to indicate the number of segments in a 
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data file, as recited in claim 13. Applicant therefore respectfully requests withdrawal of this 
basis for rejecting claim 16 under 35 U.S.C § 103(a). 

In view of the foregoing, Applicants respectfully request withdrawal of the 35 U.S.C 
§ 103(a) rejections of claims 1, 2 and 4-21 over U.S. Patent No. 6,801,536 to Foster et aL in view 
of the various cited secondary references. 

B. Conclusion 

For the reasons presented herein, Applicants submit that claims 1 , 2 and 4-21 are not 
rendered obvious under 35 U.S.C. § 103(a) by the cited references of record. Accordingly, 
reversal of the final rejection is requested, and allowance of claims 1 , 2 and 4-21 is respectfully 
requested. 



Respectfully submitted, 




Roylance, Abrams, Berdo & Goodman, L.L.P. 
1300 19 th Street, N.W., Suite 600 
Washington, D.C. 20036 
(202) 659-9076 
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VIII. CLAIMS APPENDIX 

1 . (previously presented) A receiver in a digital broadcast system comprising: 

a memory device for storing content from a transmitted broadcast signal using said 
digital broadcast system, the content comprising data files, said data files each being partitioned 
into segments that are interspersed in said transmitted broadcast signal, said transmitted 
broadcast signal being provided with at least one header comprising information indicating the 
number of said segments that constitute at least one of said data files and information to identify 
each of said segments; 

a reception device for receiving said transmitted broadcast signal and processing said 
broadcast signal to obtain at least part of said content including said segments corresponding to 
at least one of said data files therein; and 

a processing device connected to said memory device and said reception device and 
being programmable to use said at least one header in said transmitted broadcast signal to 
determine the size of at least one section in said memory device to allocate for storing the data 
file, to store said segments corresponding to the data file in said allocated section, and to 
monitor the progress of the storage of said segments in said allocated section, said at least one 
header comprising data to indicate how much of said memory device needs to be allocated to 
store the data file. 

2. (original) A receiver as claimed in claim 1, further comprising at least one output device 
connected to said processing device, said processing device being programmable to generate an 
alert message on said at least one output device when each of said segments corresponding to 
the data file has been stored in said memory device. 

3. (canceled) 

4. (original) A receiver as claimed in claim 1, wherein said segments are assigned unique 
identification codes that indicate their order in the data file, wherein said at least one header 
comprises segment headers for respective ones of said segments, said segment headers each 
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comprising a first field indicating the total number of segments in the data file, and a second 
field indicating the corresponding one of said identification codes. 

5. (original) A receiver as claimed in claim 4, wherein said processing device is operable 
to determine how much of said memory needs to be allocated to store the data file using said 
first field in the first one if said segments that is received. 

6. (original) A receiver as claimed in claim 4, wherein said segment headers comprise an 
auxiliary data field comprising an expiration data for the data file corresponding thereto. 

7. (original) A receiver as claimed in claim 4, wherein said digital broadcast system can be 
used to broadcast a plurality of messages that are each assigned a message identification code to 
indicate which of a plurality of receivers in said digital broadcast system are to receive the 
corresponding message, each of said plurality of messages comprising one of said data files, 
said segment headers further comprising a message identification code, said processing device 
being programmable to store at least one said message identification code and to discard said 
segments corresponding to said plurality of messages having a different said message 
identification code. 

8. (original) A receiver as claimed in claim 7, wherein said message identification code can 
correspond to said receivers in vehicles of a particular manufacturer and at least one of a vehicle 
model and year of manufacture. 

9. (original) A receiver as claimed in claim 1, wherein said at least one header provides a 
unique identification code for each of said segments belonging to the data file and indicates in 
what order said segments are to appear in the data file for playback, said processing device 
being programmable to determine which of said segments in the data file have not been 
received and stored in said memory device. 
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10. (original) A receiver as claimed in claim 9, wherein the data file is rebroadcast at least 
once, said processing device being operable to determine which of said segments corresponding 
to the data file have been stored and to store said segments that are rebroadcast if said segments 
are not yet stored in said memory device, and to discard said segments that are rebroadcast if 
said segments were previously stored in said memory device. 

1 1 . (original) A receiver as claimed in claim 10, wherein said processing device is provided 
with rebroadcast information and is operable to automatically operate said receiver at a selected 
time of day to receive and store said segments that are not yet stored in said memory device 
using said rebroadcast information. 

12. (original) A receiver as claimed in claim 1, wherein said memory device comprises a 
first portion for storing respective ones of said data files for which all of the corresponding said 
segments have been received, and a second portion for storing at least part of other said data 
files while said segments corresponding thereto are being received. 

13. (original) A method of transmitting content comprising data files comprising the steps 
of: 

assigning each of said data files a message identification code to indicate which of a 
plurality of receivers in said digital broadcast system are to receive the corresponding data file; 
partitioning said data files each being partitioned into segments; 

assigning said segments in respective said data files with unique identification codes that 
indicate the order of said segments in a corresponding one of said data files; 
interspersing said segments in said broadcast signal; and 

providing said broadcast signal with segment headers for respective said segments that 
each comprise a corresponding said message identification code, a first field indicating the total 
number of said segments in the corresponding one of said data files, and a second field 
indicating said identification code of the segment. 
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14. (original) A method as claimed in claim 13, further comprising the step of 
rebroadcasting said segments and corresponding said segment headers at least once 

15. (original) A method as claimed in claim 13, wherein said segment headers comprise an 
expiration date for the corresponding one of said data files 

16. (original) A method as claimed in claim 13, wherein said segment headers can 
correspond to said receivers in vehicles of a particular manufacturer and at least one of a vehicle 
model and year of manufacture. 

17. (previously presented) A method of implementing a file transfer from a broadcast 
station to a receiver in a digital broadcast system comprising the steps of: 

receiving a transmitted broadcast signal having content, said transmitted broadcast 
signal comprising content comprising data files, said data files each being partitioned into 
segments that are interspersed in said broadcast signal, said transmitted broadcast signal being 
transmitted with at least one header comprising information indicating the number of said 
segments that constitute at least one of said data files and identifying each of said segments; 

selecting one of said data files to store in a memory device; 

allocating a portion of said memory device that corresponds in size to the number of 
said segments that constitute said selected data file as indicated by said information in said at 
least one header; 

analyzing said information in said at least one header to identify said segments received 
via said transmitted broadcast signal and corresponding to said selected data file; and 

storing said segments in said portion of said memory device that correspond to said 
selected data file. 

18. (original) A method as claimed in claim 17, further comprising the step of monitoring 
which of said segments corresponding to said selected data file have not yet been received and 
stored in said portion of said memory device 



-22- 



19. (original) A method as claimed in claim 17, wherein said selected data file is 
rebroadcast at least cmce, and further comprising the steps of: 

analyzing said information relating to the rebroadcast said segments; 
storing the rebroadcast said segments that are determined to have not been previously 
stored in said portion of said memory device; and 

discarding the rebroadcast said segments that are in said portion of said memory device. 

20. (previously presented) A method as claimed in claim 17, wherein said receiver is 
provided with rebroadcast schedules for said data files and further comprising the steps of: 

determining that said portion of said memory device is a selected percentage full; 
determining via said rebroadcast schedules when the selected said data file is to be 
rebroadcast; 

operating said receiver to automatically tune to said transmitted broadcast signal when 
the selected said data file is scheduled for rebroadcast; 

extracting said segments corresponding to said selected data file have not yet been 
received and stored in said portion of said memory device; and 

storing the extracted said segments in said portion of said memory device. 

21 . (original) A method as claimed in claim 17, wherein said data files are assigned message 
identification codes to indicate which of a plurality of receivers in said digital broadcast system 
are to receive the corresponding data file, said at least one header further comprising a message 
identification code, and further comprising the steps of: 

storing at least one said message identification code in said memory device; 

locating and storing said segments received via said broadcast signal that constitute the 
data file identified via the stored said message identification code; and 

discarding said segments received via said broadcast signal that constitute said data files 
that are not identified via the stored said message identification code. 
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EVIDENCE APPENDIX 

No evidence under 37 C.F.R.. § 1 .130, 1.131 or 1 .132 is relied upon in this Appeal. 
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RELATED PROCEEDINGS APPENDIX 

None 
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